chore: add support for separate module versioning to CI #426
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- Add check-version.sh script for checking and updating module versions - Update update-version.sh to handle module-specific tags - Add new check-version npm script This change allows tracking module versions separately using tags in the format release/module-name/v1.0.0 and adds tooling to verify README.md versions match the tags.
- Replace update-version.sh and check-version.sh with modules-version.sh - Add support for semantic versioning (patch, minor, major) - Add tag creation capability - Improve CLI interface with better help and options - Update package.json scripts for the new tool
- Replace old version check mechanism with new --check mode - Improve error messaging for version mismatches - Simplify CI configuration
- Differentiate between PR checks and main branch checks - For PRs: Verify version is incremented but doesn't need to match tags - For main: Verify versions match tags - Add helpful error messages with specific commands to fix issues - Handle modules without tags gracefully
- Make version check informational only for PRs - Add ability to skip check with [skip-version-check] in commit message - Remove complex logic in favor of simpler workflow - Ensure developers retain control over versioning
- Split version check into separate steps with clear purposes - Use GitHub context properly for checking PR vs main branch - Add step outputs for better workflow control - Improve messaging with emojis for better readability - Maintain ability to skip checks when needed
- Remove the ability to skip version checks via commit message - Simplify version check logic to only run on pull requests - Update messaging for clarity and maintain informational checks for changed modules
- Streamline the release process instructions for better clarity - Emphasize the importance of creating a PR and updating the README version - Remove outdated steps and consolidate information on automated publishing
matifali
changed the title
mafredri
approved these changes
Apr 14, 2025
There was a problem hiding this comment.
It's unclear to me why --set-version or --tag is needed. I think a --bump=patch combined with --dry-run to see changes might be preferable. (Less modes of operation would make this script more approachable).
Other than the size/complexity of the script, looks good. Left some suggestions but I leave it up to you.
…functionality - Replace --check with --dry-run for clearer functionality - Remove --set-version option to simplify script usage - Keep only --bump=patch|minor|major for version updates - Update CONTRIBUTING.md with clear examples of script usage - Update CI workflow and package.json to use new options
- Update versioning workflow to create tags first, then PRs - Use annotated tags with commit messages - Add --auto-pr option to create PRs by github-actions[bot] - Update CONTRIBUTING.md with new workflow examples - Update CI workflow and package.json accordingly
…are pushed - Create workflow to update README when module tag is pushed - The workflow creates a PR as github-actions[bot] - Simplify module-version.sh to just handle tag creation - Update CONTRIBUTING.md with the new workflow details - Update package.json scripts
- Add auto-approval step using hmarr/auto-approve-action - Enable auto-merge using GitHub CLI - Update CONTRIBUTING.md to reflect fully automated process
- Add support for EXACT_VERSION environment variable - Replace bump_version with get_version function - Use existing script in GitHub Action workflow - Minimize code duplication between script and workflow
- Add --version=X.Y.Z parameter to set exact versions - Update get_version to use CLI option, environment variable, or bump logic in priority order - Update GitHub Action to use the new parameter instead of environment variable - Update documentation with examples using the new parameter
- Remove EXACT_VERSION environment variable support - Simplify get_version function to only use command-line arguments - Maintain only two options: --version or --bump
- Update CONTRIBUTING.md to reflect new tag-first workflow - Clarify that contributors don't need to update README versions manually - Remove version check from CI workflow as it's no longer needed - Update documentation with numbered steps for clarity
- Create release.sh for maintainers to create tags - Create update-version.sh for README version updates - Update GitHub workflow to use the new scripts - Update CONTRIBUTING.md with new script examples - Add --list option to release.sh to show module versions - Update package.json scripts
- Simplify update-version.sh to focus on version updates only - Simplify release.sh to only handle tag creation and listing - Remove the old modules-version.sh script - Use update-version.sh --check in the GitHub workflow - Rename functions for better clarity - Remove any --bump functionality as it's not needed
- Simplify update-version.sh to use positional arguments only - Simplify release.sh to have minimal options - Update GitHub workflow to match new script interfaces - Keep only essential features like --list and --dry-run - Update CONTRIBUTING.md to reflect simplified commands
- Replace peter-evans/create-pull-request with gh CLI - Set github-actions[bot] as PR author - Request review from cdr-bot for approval - Enable auto-merge using the gh pr merge command - Extract PR number for proper API integration
- Change PR author to cdrci - Implement auto-approve using hmarr/auto-approve-action - Follow GitHub's recommended pattern for auto-approval - Separate PR creation and approval into distinct steps - Pass PR number between steps using GITHUB_OUTPUT
- Remove all superfluous comments from scripts - Simplify scripts to be more concise - Streamline GitHub Actions workflow syntax - Keep only essential code and explanations
- Add explanatory comments to update-version.sh - Add detailed section comments to release.sh - Add workflow-level comments to GitHub Actions file - Explain purpose of each major code section - Enhance readability for maintainers and reviewers
|
@mafredri I ended up redoing most of it. I feel confident this is better and more flexible than the original approach. |
mafredri
previously requested changes
Apr 15, 2025
CONTRIBUTING.md
Outdated
| ./release.sh module-name 1.2.3 | ||
|
|
||
| # Push the tag to the repository | ||
| git push origin release/module-name/v1.2.3 |
There was a problem hiding this comment.
One issue with this approach is that the tag will not include the updated README, it'll be updated after tagging meaning when you git checkout release/module-name/v1.2.3 the README will state v1.2.2.
It's perhaps a minor thing, but makes me question the release method.
There was a problem hiding this comment.
Nice observation. Do you have any suggestions on a better approach?
We would have to reverse the behavior where the user chooses a tag, commits that to README, and then pushes a tag that matches that.
That will have more responsibility on the maintainer and can resurface #229.
update-version.sh
Outdated
| } | ||
| ' "$file" > "$tmpfile" && mv "$tmpfile" "$file" | ||
There was a problem hiding this comment.
Perhaps undo the awk changes, they don't make things better or clearer.
|
I would suggest reviewing the PR without looking at the diff. |
Deleting this as we will handle version constraints in a separate PR
mafredri
approved these changes
Apr 22, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This pull request introduces significant changes to streamline the release process, improve version management, and enhance documentation formatting. The key updates include adding new scripts for release tagging and version updates, removing outdated scripts, and revising the release documentation.
Release Process Improvements:
release.shscript to automate the creation of annotated git tags for module releases, with options for listing modules, dry runs, and pushing tags to the remote repository.update-version.shscript with a more robustupdate_version.shscript that supports both updating and checking module versions inREADME.mdfiles. [1] [2]CI Workflow Updates:
.github/workflows/ci.yaml, as the new release and version management scripts make it redundant.Documentation Enhancements:
CONTRIBUTING.mdto reflect the new automated workflow, replacing the previous manual steps with instructions on usingrelease.sh.CONTRIBUTING.mdby replacing plain markdown notes with[!NOTE]syntax for better readability.Codebase Simplification:
fmtscript inpackage.jsonto include new shell scripts (terraform_validate.sh,release.sh,update_version.sh) in formatting checks, and removed the obsoleteupdate-versionscript entry.